Prevent multiple simultaneous WeConnect API calls on start up #245
Conversation
| import logging | ||
| import asyncio | ||
| import threading |
There was a problem hiding this comment.
This may look alarmingly like I’m replacing asyncio with threading, but not really! 😀 asyncio was deleted simply because it was not being used in this module (even before this PR), and threading was added for the use of threading.Lock.
By the way, this PR does not cause any threads to be spawn or any new execution parallelism. The threads were already there before this PR, making multiple parallel calls to the WeConnect API. This PR simply adds some thread coordination to prevent unnecessary API calls.
|
This would explain why I always get blocked for a few hours when I restart Home Assistant a few times! |
|
If you fix the conflict i will merge your change! :) |
pdcastro
force-pushed
the
duplicate-api-calls-on-start
branch
from
9ad6ea1 to
2539ddf
Compare
Done! 👍 |
Thanks for creating and maintaining this integration! 👍
I have observed that it is the last integration to finish loading whenever I (re)start my Home Assistant instance. I have found that, when the integration starts, it makes 6 calls to the WeConnect API
update()method nearly at once — the sameapi.update()call that is normally made every 45 seconds. Each such call results in 6 HTTP GET requests to the following VW/Cariad endpoints:https://emea.bff.cariad.digital/vehicle/v1/vehicleshttps://emea.bff.cariad.digital/vehicle/v1/vehicles/<VIN>/selectivestatus?jobs=access,activeventilation,automation,auxiliaryheating,userCapabilities,charging,chargingProfiles,batteryChargingCare,climatisation,climatisationTimers,departureTimers,fuelStatus,vehicleLights,lvBattery,readiness,vehicleHealthInspection,vehicleHealthWarnings,oilLevel,measurements,batterySupport,tripshttps://emea.bff.cariad.digital/vehicle/v1/vehicles/<VIN>/parkingpositionhttps://emea.bff.cariad.digital/vehicle/v1/trips/<VIN>/shortterm/lasthttps://emea.bff.cariad.digital/vehicle/v1/trips/<VIN>/longterm/lasthttps://emea.bff.cariad.digital/vehicle/v1/trips/<VIN>/cyclic/lastSo 6 × 6 = 36 authenticated API endpoint requests within a few seconds from the integration being loaded (in my logs I observed all HTTP requests being started within 3 seconds of the integration loading). In addition, when the config flow executes during installation, an extra
api.update()call is made for username and password validation, in which case it is 7 × 6 = 42 authenticated API endpoint requests just a few seconds apart.2 of the 6 or 7
update()calls are explicit, and the others happen as a result of calls tocoordinator.async_config_entry_first_refresh():__init__.py#L49__init__.py#L79binary_sensor.py#L139device_tracker.py#L29number.py#L29sensor.py#L448config_flow.py#L41I have verified this finding by adding debug logging at the relevant WeConnect fetchData
session.get()call.A single WeConnect API
update()call would be sufficient at start up. This PR proposes a relatively simple solution to achieve this, even in the config flow scenario when the integration is installed.I tested my solution with HASS version 2024.1.6, including the case of the user entering incorrect username and password in the config flow. I have also exercised the code added to
async_unload_entry()by deleting and re-adding the integration.